在这篇文章里，我要和大家分享一段跨越500天的主数据项目实践之旅。这不只是技术实现的故事，更多的是关于团队协同、决策的考验与数据治理的探索。从项目初步构想到最终成功上线，我们经历了很多挑战，如决策的纠结、认知差异、系统的复杂度以及项目中的种种不确定性。请随我一起，一同探索这段旅程的起伏和转折。现实世界中的每一个地址，都代表着一个家庭或者商业客户。对于运营商来说每一个地址也就意味着一个市场机会，梳理清楚了地址数据也就掌握了整个潜在的发展市场。
由于原来采用烟囱式的管理模式，公司地址数据分布在BOM三域多个业务系统，不同业务系统的地址数据格式和标准均不相同，使得前后端协同的效率降低，例如，市场前端需要基于小区地址进行宽带攻坚，但网络后端家宽覆盖地址的信息无法准确匹配到，这样就影响到了家宽网络的扩容。
正是在这样的背景下，公司决定启动地址主数据系统的建设。首先我们来看下项目的时间线：202203 公司数据治理联席会议第一次会议，管理层提出地址主数据统一管理的要求202204 公司数据治理联席会议第二次会议，地址数据现状和统一管理思路汇报，决策由数据管理部牵头建设202206 公司数据治理联席会议第三次会议，地址数据整合方案汇报，汇报全量地址目标库建设思路202207 公司数据治理联席会议第四次会议，地址主数据系统建设方案汇报，计划分三个阶段推进地址主数据系统的建设，明确项目组织和主要建设内容202208 公司数据治理联席会议第五次会议，地址相关业务流程梳理情况汇报，各业务部门汇报地址相关业务流程梳理情况和录入规范情况202210 第六次会议，部门内地址主数据项目阶段汇报，明确运维职责由于地址数据涉及前端家宽销售、后端资源开通等大量生产流程环节，跟公司主要的前后端部门都息息相关，公司层面前前后后开了六次会议进行讨论，主要围绕三个核心问题进行决策：我们选择了职责最清晰，但挑战最大的一种，即由第三方数据管理部来负责，因为数据管理部属于企业级数据管理部门，相对中立，同时本身就有数据治理职能。挑战最大是因为其没有地址相关系统建设和管理经验，需要从0到1去整合各类地址系统的存量数据，沟通协调的挑战比较大。第二，到底采用哪种主数据管理方案？是集中管理还是分布式管理，是新建一套系统还是选择一个存量系统进行扩展升级？由于公司前期决策是由一个新的数据管理组织来负责建设和运营主数据系统，最后公司还是倾向选择新建一套集中化的主数据系统的方案，这其实是组织架构决定系统架构的体现，当然这种架构也带来了可能的性能瓶颈和单点故障的风险。
考虑到地址信息可能会改变我们的前端业务流程，还可能会影响到第一线的员工如何使用，所以在开始系统设计之前，必须仔细分析这个问题。公司决定让数据管理部门来负责这项工作。我们不仅需要规划出详细的流程，并创建一个统一的模板，还要和其他相关部门一起协作，确保每个流程都能顺利进行。这对数据管理部门的专业和团队协作能力都是一个挑战。
总体来讲，决策的过程还是比较长的，因为各部门有自己的站位和难处，自身所在的团队也有各种局限性，比如很多的技术思维，不熟悉相关业务和系统等等，最后还得由公司领导一锤定音。当老板在第一次数据治理联席会议上说要我们统一处理公司的地址信息，并希望我们团队来主导时，我们都有点懵。虽然我做数据的时间不短，知道主数据管理是什么，但对公司的地址信息和相关业务真的不太了解，这让我有点担心。
做好企业级的数据治理，需要打破部门壁垒。虽然公司已经建立了企业级的数据治理组织，但大家的想法可能还停留在之前。我一开始也是，还是习惯于为自己的工作划定清晰的边界，当任务超出这些边界时，就会有所犹豫，这也是我的个人局限。
比如梳理业务流程，我觉得这应该是业务部门的事，技术部门来主导似乎不太对头。但后来意识到这种思维还是太局限了。数据治理其实就是要处理这种不清不楚的事。知道有问题，知道自己做可能有局限，但总得有人勇敢地迈出第一步。
事后我也做了总结，发现对于跨部门的事，只要有公司领导的实际支持，不说做到最好，但总是可以做得比以前好一点，即“追求进步，而非完美”，关键还是要有些勇气和担当。
身为技术管理者，我对技术工作很感兴趣，它相对纯粹，可以说技术是我的舒适区。虽然必要的上层汇报和同级沟通不可避免，但它们占用的时间比例不高。
然而，当我开始从事主数据工作时，事情变得相反。长时间里，我很少关注技术管理，而是忙于为公司的数据治理联席会议做准备，并处理各种跨部门的议题，涉及组织、技术和资源等。在这段时间里，我牵头了六次联席会议，并为每一次做专题汇报。大量的准备和协调工作让人焦虑，因为很多东西不是你说了算，什么都要商量着来，而且时间还不确定。
例如，每次会议前，我都要电话沟通关于报告的内容，确认是否有异议。对于存在异议的内容，我们需要详细记录以便应对，还必须提前一周与各部门领导确认他们的出席情况，并在会议前通过微信再次确认，因为许多关键决策需要领域负责人的意见。有一次，某部门的领导因紧急事务缺席，虽然他指派了其他人员代表，但决策效果显然不如预期。
实际上，不只是我一个人在努力协调，整个主数据项目组也都在忙于此事。每当我听到团队成员在隔壁与其他部门讨论主数据方案时，我总会有些担忧，担心原定的方案会被否定，这意味着我们需要重新规划。比如，我们最初理想地认为通过API提供主数据服务就足够了，但后来发现某些部门的系统需要物理数据表，这又引发了数据一致性问题。这样的挑战很多。
尽管我对主数据有基本的了解，但实际操作经验是缺乏的，大家都面临同样的问题。作为主导部门，能否赢得各部门的信任变得尤为关键，因此此刻，快速的学习和适应能力显得至关重要。
主数据与公司的业务、数据和系统紧密相关。在短时间内找到一个完全合适的供应商不太可能，因此我们只能依赖团队内部的资源。我和我的团队迅速查阅了所有可用的主数据相关资料，并开始深入的系统调研。我们的目标是清晰地分析地址数据的不一致性，并在系统、数据和业务上找到解决方案。但这一任务十分繁重，因为涉及的地址数据量大且复杂。
经过四个月的努力，我们终于完成了方案的定稿，期间经历了无数次的修改。最具挑战性的部分是数据整合方案，我们需要重新设定标准，反复研究建模方法，并清洗数亿的存量数据。接着是业务流程改革方案，起初各业务部门提供的流程较为混乱，我们为此专门设计了一个统一的流程模板，并附带了一个示例，目的不仅是帮助我们自己理解，还希望可以指导其他人。最后就是系统方案，由于涉及的系统众多，我们需要构建一套横跨BOM三域、融合OLAP和OLTP的全新系统架构，这对于数据中台团队来说都是新的东西，需要重新学习。
首先，地址主数据系统采用的是最彻底的集中化的主数据系统架构，即“一点采集，统一服务”，好处是能确保地址数据的一致性，坏处是实施难度很高，不仅要求剥离资管、CRM等系统原有的独立的地址数据管理模块，新建一套全新的主数据系统，还要对原有所有系统进行适配改造。我们所以果断的采用这种架构，也许是因为我们在数据管理方面的积累还不错，也许是太过自信了。后来我发现坑还是很多的，整个方案来来回回近半年时间，难度远远超出原来的设想，同时单点故障等架构的隐患也让项目组非常头痛。其次，地址主数据系统设计之初就不是单一的系统，而是包括生产服务、地址管理、地址分析三大子系统，这三个系统分属OLAP+OLTP不同的类型，生产服务子系统为CRM、资管等外围应用提供地址新增、变更、查询、分发等生产性服务，地址分析和管理子系统通过稽核分析的手段将新增/变更的地址数据纳入生产，从而共同支撑地址数据的闭环管理，我们建设的其实不仅仅是一个IT系统，更是要打造一个地址数据的闭环管理体系，复杂度还是比较高的，最后的系统架构如下所示：最后，地址数据是非常有价值的数据资产，我们这一次做的不仅仅是内部存量地址的整合，还要尽可能的把各种外部地址数据尽量的采集全面，包括采买的地图地址数据、一线排摸的地址数据、POI数据、爬取的各种外围地址数据等等。在这些地址数据的基础上，我们制定了13+N的标准，自研了清洗算法，最终得到了一份超1亿条的标准地址数据。整个数据处理的过程耗时半年。地址主数据系统的项目结构较为复杂。虽然有公司领导挂帅,成立了项目领导小组及工作小组,但涉及的相关部门达9个之多,工作小组下挂的专业组就有5个之多，分别是系统架构组，平台建设组，数据建模组，O域改造组及B域改造组，如下所示：这样复杂的项目团队结构，决定了项目控制的难度。我对此感受最深的有以下三点:地址数据的整合是项目成功的关键。在这方面，数据中台团队还是比较有优势的，他们不仅拥有丰富的数据处理经验，还具备AI能力。然而，我们的地址主数据系统不只是用于分析的工具，它更是一个要求高连续性、跨多个领域的企业生产系统，因此系统的稳定性是非常关键的。在稳定性方面，业务中台团队显然更有经验。如何结合两支团队的特点，进行有效的协作，是我们在项目管理上要面对的挑战。
经过考虑，我们决定由CRM业务中台团队主导实施，与数据中台团队紧密协作。这种合作方式虽然在初期曾出现团队之间的责任不明确、进度不同步、OLAP与OLTP数据同步问题等挑战，但从总体上看，这确实是一个有效的协作模式。首先，我们对数据团队有很好的控制和了解，这降低了许多沟通成本。其次，业务中台团队的加入为数据团队带来了稀缺的能力，使我们最终能克服系统稳定性的问题。
项目最初计划在6-8个月内完成，但由于与其他部门协同工作的难度，导致进度远超预期。我们的项目经理过去主要在某一专业领域工作，对于涉及跨领域的大型项目显然缺乏经验，我也是如此。在这超过一年的项目周期里，除了初期的方案汇报，我们几乎没有在公司层面进行过其他阶段性汇报。当时的考虑是，组织汇报会议涉及太多事务性工作，尽量避免为好。但现在看来，这确实是战略上的疏忽。
同时，也存在一些战术上的问题。如，项目前期与各部门的共识不足，原先制定的时间计划未得到其他部门的明确确认；执行阶段的控制不够严格，每周的会议常有部门缺席；项目进度和问题缺乏透明度，在遇到问题时往往采用自己解决的方式，而不是及时升级。
当时，我还同时负责对接集团公司财务系统集中化的本地支持工作。在项目期间，无论是论证、启动、调研、方案设计、动员、检查、上线或总结等会议，集团公司都是事无巨细，现在回想起来，发现这些手段的确有助于大家形成共识和确保项目的顺利进行。当然财务集中化有条线管理的优势，企业级数据治理横向协调的难度会更大一点，但道理是一样的。做事总是要虚实结合，适当的虚是为了更好的实，我在这方面的度把握的还不是很好。
地址主数据项目由我们的数据管理团队负责。但由于团队之前缺乏地址数据的建设和运营经验，我们往往走得更像是一条理想化的路径。而实际上，不同系统领域对地址数据服务的需求在形式、及时性和准确性上都各有差异。项目的整个过程就像是一个不断学习和包容的旅程。以下三个点给我留下了深刻的印象：数据一致性的挑战：虽然项目组初衷是以API的方式提供地址服务以确保数据一致性，但我们意识到资管系统实际上需要同步一份地址数据副本。这样，它们才能在本地进行高效、灵活的二次处理以为各自领域提供服务。虽然这可能会引入一些数据一致性的问题，但它确实是一个相对低风险的解决方案。业务影响的控制：我们曾提议制定地址数据录入规范，并希望一线人员按照“13+N”的标准进行分段录入。但这一改变所需的成本实在过高。最终，我们与业务人员达成共识：维持前端的录入流程，并采用AI技术标准化前台录入数据。但某些工程管理岗位的人员仍需遵守该标准。降低割接风险：为了减少割接对生产环境的影响，我们采纳了领域专家的建议，通过映射存量地址ID和新ID来实现地址格式的兼容性，而不对存量系统进行大的改造。尽管这样会为存量系统的地址表带来一些冗余，但这无疑是性价比最高的方法。但我们始终能坚守底线，即“集中控制，统一分发”。在这基础上，愿意探讨并采纳各种折中的解决方案。